tests: add xen-guest-agent integration tests by d3athjest3r · Pull Request #434 · xcp-ng/xcp-ng-tests

d3athjest3r · 2026-03-23T15:35:17Z

Description

Add a test suite that validates the xen-guest-agent daemon running inside a guest VM correctly publishes data to Xenstore. The conftest downloads RPM and DEB packages from the xen-guest-agent GitLab CI artifacts and SCPs them to the VM for installation.
The test class (TestXenGuestAgent) then installs the agent on the VM via yum (RPM distros) or dpkg (APT distros), then verifies:

the systemd service is active after install and after reboot
Xenstore paths for version, OS info, memory and VIF IP are populated (meminfo_free is polled with a 90s timeout as it is only published on a 60s timer; the VIF/IP check is skipped if no Xen PV NIC is present)

glehmann

I'm not sure we need the complex logic to find and download the last version.
There are not that many releases, so a simple URL should be enough IMO.
I think that would also allow downloading the file directly on the VM

glehmann · 2026-03-23T21:22:02Z

tests/guest_tools/unix/test_xen_guest_agent.py

+        # Remove conflicting xe-guest-utilities if present
+        logging.info("Removing xe-guest-utilities if present")
+        if pkg_mgr == PackageManagerEnum.RPM:
+            vm.execute_script('rpm -qa | grep xe-guest-utilities | xargs --no-run-if-empty rpm -e')


You can use vm.ssh(…) here

Suggested change

vm.execute_script('rpm -qa | grep xe-guest-utilities | xargs --no-run-if-empty rpm -e')

vm.ssh('rpm -qa | grep xe-guest-utilities | xargs --no-run-if-empty rpm -e')

Yes. Thanks. Addressed.

glehmann · 2026-03-23T21:33:42Z

tests/guest_tools/unix/test_xen_guest_agent.py

+        # VIF detection requires a Xen PV NIC; skip if none was detected
+        if host.ssh_with_result(['xenstore-exists', f'{xs_prefix}/attr/vif']).returncode != 0:
+            pytest.skip("No VIF published in Xenstore — VM may not be using a Xen PV NIC")
+        published_ip = host.ssh(['xenstore-read', f'{xs_prefix}/attr/vif/0/ipv4/0'])


We have some IPv6-only tests, so this should probably test for both ip v4 and v6 addresses.

yes. Addressed. I have added IPv6 support.

glehmann · 2026-03-23T21:42:43Z

tests/guest_tools/unix/test_xen_guest_agent.py

+        if pkg_mgr == PackageManagerEnum.RPM:
+            vm.ssh(['yum', 'remove', '-y', 'xen-guest-agent'])
+        if pkg_mgr == PackageManagerEnum.APT_GET:
+            vm.ssh(['apt-get', 'remove', '-y', 'xen-guest-agent'])


Not sure if this is useful, but the previously removed xe-guest-utilities is not restored here

Yes, I have dropped all this. The VM will be destroyed anyway afterwards.

d3athjest3r · 2026-03-24T13:04:26Z

I'm not sure we need the complex logic to find and download the last version. There are not that many releases, so a simple URL should be enough IMO. I think that would also allow downloading the file directly on the VM

Ok. But the URLs are not easy to find or to browse. What would be a "stable" URL to fetch the deb packages and the rpms from? I have, e.g., https://gitlab.com/xen-project/xen-guest-agent/-/releases. But they don't directly contain the RPMs or DEBs, I would have to extract the links to the successful pipeline artifacts, and download from there. Moreover, these paths are not aligned. One is artifacts/browse/RPMS/x86_64/ and one is artifacts/browse/RPMS/x86_64/. Would this be stable across releases? For the deb packages I could download it via https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64/release-0.4.0/xen-guest-agent_0.4.0_amd64.deb. But for the RPMs this doesn't work. Any suggestions? @ydirson @dinhngtu @fallen

glehmann · 2026-03-24T13:30:33Z

They are stable as in "they won't go away", but not stable as in "we'll keep the same URL for a new release".

Updating the package URL in a PR instead of doing it automatically during the test would also prevent breaking the build in an unplanned way if the new package introduces a regression.

Other opinions are welcome :)

d3athjest3r · 2026-03-24T13:44:19Z

https://gitlab.com/xen-project/xen-guest-agent/-/jobs/6041686376/artifacts/raw/RPMS/x86_64/xen-guest-agent-0.4.0-0.fc37.x86_64.rpm

https://gitlab.com/xen-project/xen-guest-agent/-/jobs/6041686362/artifacts/raw/target/release/xen-guest-agent_0.4.0_amd64.deb

They are stable as in "they won't go away", but not stable as in "we'll keep the same URL for a new release".

Updating the package URL in a PR instead of doing it automatically during the test would also prevent breaking the build in an unplanned way if the new package introduces a regression.

Other opinions are welcome :)

Ping @tperard

tperard · 2026-03-24T15:15:11Z

https://gitlab.com/xen-project/xen-guest-agent/-/jobs/6041686376/artifacts/raw/RPMS/x86_64/xen-guest-agent-0.4.0-0.fc37.x86_64.rpm
They are stable as in "they won't go away"

I disagree, URL based on a job_id can disappear from the day to the next, if we change setting on the project to keep only the artefact of the latest pipeline (on a branch) or change the retention to delete old artefacts. We should rely on a branch name or a tag instead.

There's Download job artifacts by reference name which makes it simple enough to download the needed artefact.

That would give us, for the main branch:

And replace main by 0.4.0 in the URL for the latest tag.

But that download all the artefacts as an archive, but there's another API to get one file only, if you know the path, e.g.:

https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/jobs/artifacts/0.4.0/raw/target/release/xen-guest-agent_0.4.0_amd64.deb?search_recent_successful_pipelines=true&job=pkg-deb-amd64

With the full archive, you could just extract it, and install all the *.deb or all the *.rpm without needed to figure out the filename.

I've just notice that the two proposed "stable" URL seems to be from tag 0.4.0. I would rather have a self describing URL, but a looking random url with a description in a comment can work too, at the risk that the comment is getting out-of-sync as soon as we update the url.

d3athjest3r · 2026-03-24T15:21:35Z

https://gitlab.com/xen-project/xen-guest-agent/-/jobs/6041686376/artifacts/raw/RPMS/x86_64/xen-guest-agent-0.4.0-0.fc37.x86_64.rpm
They are stable as in "they won't go away"

I disagree, URL based on a job_id can disappear from the day to the next, if we change setting on the project to keep only the artefact of the latest pipeline (on a branch) or change the retention to delete old artefacts. We should rely on a branch name or a tag instead.

There's Download job artifacts by reference name which makes it simple enough to download the needed artefact.

That would give us, for the main branch:
* https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/jobs/artifacts/main/download?search_recent_successful_pipelines=true&job=pkg-deb-amd64

* https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/jobs/artifacts/main/download?search_recent_successful_pipelines=true&job=pkg-rpm-x86_64
And replace main by 0.4.0 in the URL for the latest tag.

But that download all the artefacts as an archive, but there's another API to get one file only, if you know the path, e.g.:
* https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/jobs/artifacts/0.4.0/raw/target/release/xen-guest-agent_0.4.0_amd64.deb?search_recent_successful_pipelines=true&job=pkg-deb-amd64
With the full archive, you could just extract it, and install all the *.deb or all the *.rpm without needed to figure out the filename.

I've just notice that the two proposed "stable" URL seems to be from tag 0.4.0. I would rather have a self describing URL, but a looking random url with a description in a comment can work too, at the risk that the comment is getting out-of-sync as soon as we update the url.

Ah nice that's ok. I already have code that extracts the rpms and debs from the archive. With your URL just the {deb,rpm} needs to be set for each archive. This would also always test the latest successful build. I think this is great. This way we make sure we don't have any regressions.

Add a test suite that validates the xen-guest-agent daemon running inside a guest VM correctly publishes data to Xenstore. The conftest downloads RPM and DEB packages from the xen-guest-agent GitLab CI artifacts and SCPs them to the VM for installation. The test class (TestXenGuestAgent) then installs the agent on the VM via yum (RPM distros) or dpkg (APT distros), then verifies: - the systemd service is active after install and after reboot - Xenstore paths for version, OS info, memory and VIF IP are populated (meminfo_free is polled with a 90s timeout as it is only published on a 60s timer; the VIF/IP check is skipped if no Xen PV NIC is present) Signed-off-by: Julian Vetter <julian.vetter@vates.tech>

glehmann · 2026-03-24T16:59:41Z

Note that the URLs I proposed are just the ones from the release page, which have been there for 2 years, so let's say "kind of stable" :)
I also prefer the URLs proposed by @tperard.

Any opinion on:

the last version vs a specific version
downloading directly on the VM vs downloading on the runner then copying on the VM?

@xcp-ng/os-platform-release

d3athjest3r requested review from a team as code owners March 23, 2026 15:35

glehmann reviewed Mar 23, 2026

View reviewed changes

d3athjest3r force-pushed the test_rust_guest_agent branch from 9ce50ba to 86662db Compare March 24, 2026 15:46

d3athjest3r force-pushed the test_rust_guest_agent branch from 86662db to 807c506 Compare March 24, 2026 15:49

	vm.execute_script('rpm -qa \| grep xe-guest-utilities \| xargs --no-run-if-empty rpm -e')
	vm.ssh('rpm -qa \| grep xe-guest-utilities \| xargs --no-run-if-empty rpm -e')

Conversation

d3athjest3r commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

glehmann left a comment

Choose a reason for hiding this comment

Uh oh!

glehmann Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

d3athjest3r Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

glehmann Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

d3athjest3r Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

glehmann Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

d3athjest3r Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

d3athjest3r commented Mar 24, 2026

Uh oh!

glehmann commented Mar 24, 2026

Uh oh!

d3athjest3r commented Mar 24, 2026

Uh oh!

tperard commented Mar 24, 2026

Uh oh!

d3athjest3r commented Mar 24, 2026

Uh oh!

glehmann commented Mar 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

d3athjest3r commented Mar 23, 2026 •

edited

Loading